The conventional approach to updating real-time services is to stop the existing services and then to start the updated versions thereof. This may be a particularly slow process in the case of network-distributed services that are hosted on multiple hosts, all of which may need to be updated and synchronized before the service becomes ready to handle client requests.
The delay in stopping the existing distributed services, and the further delay in starting the updated services, leads to downtime of the service. This downtime causes delays in processing of packets intended for the service, which may be unacceptable for a real-time service, which may be intended to satisfy a request within several seconds, a second, or even a fraction of a second. For example, a particular real-time high-frequency stock trading service might be intended to satisfy a buy or sell request within one or two seconds. If the stock trading service is updated, requiring stopping the existing processes implementing the service and starting the updated processes and thereby causing a delay of several minutes, large numbers of trade requests will fail to be fulfilled in the interim, possibly leading to customer dissatisfaction and/or large losses of revenue.